The Real Time Transport Protocol (RTP) is the primary protocol used for real time media transport over Internet Protocol (IP) networks. The RTP protocol is used for carrying voice, video, real time text, and other media types. In order to assess the reception quality of an RTP media stream, an associated Real Time Control Protocol (RTCP) feedback channel is used by the receiver to send information back to the sender.
There are a number of cases where it is undesirable to play out media. For example, a session setup protocol may wish to assess media channel viability before committing to forming a full media session and before alerting a user of a media call. It also may be undesirable to play out media when doing synthetic load testing or when there is a need to fill a channel to a constant packet rate to emulate a constant-bit-rate encoder or to foil traffic analysis attacks.
In one example, a first party may make an IP phone call to a second party. A signaling protocol is used to establish the phone call. The call signaling path may be operating correctly, thus allowing a signaling stream between the two parties. However, the media path is different from the signaling path. This means the correct operation of the signaling exchanges does not imply the ability to successfully exchange media packets.
Other communication networks, such as a Public Switched Telephone Network (PSTN) have the ability through mechanisms like Continuity Test (COT) to delay media play out while determining the viability of the media channel. A similar capability is desirable for Internet Protocol (IP) networks. It would be desirable to implement this capability with minimal or no new protocol machinery, and within the confines of existing IP standards.
Ideas have been proposed even in the packet domain for sending certain test packets for verifying that a media stream can be adequately supported over the IP network. Previous ideas include sending ping-pong packets or sending Named Signaling Events (NSEs) as described in RFC2833. Other ideas have suggested sending early media, or using “probe” packets before establishing the call. However, these ideas require awkward associations of RTP streams and non-standard behavior of endpoints.
The test packets may use an independent test path which presents several problems. First the test path and the media path may take different routes over the IP network. Another problem is that the test packets in the test path may be processed in the receiving device in a different way than the media stream received in the media path.